Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000027_owner-urn-ietf _Wed Mar 12 12:29:34 1997.msg

Internet Message Format | 1997-04-01 | 17KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id MAA02214
    for urn-ietf-out; Wed, 12 Mar 1997 12:29:34 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA02209
    for <[e-mail]>; Wed, 12 Mar 1997 12:29:29 -0500 (EST)
Received: from mailhub.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA22915  (mail destined for [e-mail]); Wed, 12 Mar 97 12:29:22 -0500
Received: from ferao.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 12 Mar 1997 17:01:22 +0000
Received: from phao.jungle.bt.co.uk by ferao.jungle.bt.co.uk (Jungle-SMTP-01) ID AA26040; Wed, 12 Mar 1997 16:56:41 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 17:03:49 +0000
To: "Kindel, Charlie" <[e-mail]>,
        "Watson, Andrew" <[e-mail]>
From: Bob Briscoe <[e-mail]>
Subject: [URN] The IETF Uniform Resource Names Working Group invites your comments
Cc: [e-mail], [e-mail] (Leslie Daigle)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

Charlie, Andrew,

Leslie Daigle, the co-chair of the IETF URN working group has asked me to
invite you two to comment on a problem I have just thrown into the IETF URN
working group. Alternatively can you forward this to someone with the time
and equivalent expertise to look into this?

The question is do you think the NAPTR proposal (see below) could be made
to assimilate both "clsid:" and "IOR:" identifier schemes as a global
naming glue?

To catch up on the conversation so far, see the mailing list archive at
ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive/urn-ietf.archive.970
3 - then search for the string "Interface References" in the subject line.
I have attached the 3 postings in this thread so far as the archive is not
ordered by thread.

To catch up on the proposal at issue, see the Internet draft at:
http://www.acl.lanl.gov/URN/naptr.txt (identical to
draft-ietf-urn-naptr-03.txt in your favourite internet-drafts directory).

Bob

---No 1 in thread---
>>>Date: Tue, 11 Mar 1997 14:59:39 +0000
>>>To: [e-mail]
>>>From: Bob Briscoe <[e-mail]>
>>>Subject: URNs grandfathering certain Object or Interface References
>>>
>>>Apologies if this has already covered - I've not being reading the URN
list too carefully recently, but a scan of the archive and the latest NAPTR
draft makes me think I have identified a new problem.
>>>
>>>The NAPTR proposal has a regexp/replacement field based on sed which is
a text based transformation.
>>>
>>>DCE universally unique id's (UUIDs) used by Microsoft's COM (as well as
DCE) and CORBA/2 Interoperable Object References (IORs) are typically
generated to include a references to the service for resolving them but
they can both be stringified to end up being a string of hex characters.
Proposals have been put forward to introduce these as new URL schemes.
>>>
>>>Refer to:
>>>The "clsid:" URL Scheme, Charlie Kindel, Microsoft Corporation, Feb 28
1996 Draft, <URL:http://www.w3.org/pub/WWW/Addressing/clsid-scheme>
>>>
>>>CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.6.5 Stringified Object References]
>>>
>>>You end up with URLs like:
>>>clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>>or
>>>IOR:000000000000001b9444c3a48656c6c6f576f726c642f476f6f644461793a312e3000
00000000010000000000000044000100000000000e3133302e31303a22e3137362e3900d7820
000002800504d43000000010000001448656c6c6f576f726c643a3a476f6f644461790000000
002cc52247e
>>>
>>>I don't know to much about UUIDS but I know that IORs are intended to be
semi-resolvable outside the domain in which their id has true context, at
least to the extent that the services they rely on for resolution, and the
originating domain can be identified.
>>>
>>>The problem is that some COM/CORBA based systems can interpret these
strings of hex digits to extract the machine/port etc. which hosts the
object they need for resolution, but the algorithm isn't a simple textual
transformation.
>>>
>>>How might NAPTR cope with this without just resorting to a replacement
string and lumping the whole problem on one global resolver for the whole
scheme leading to a horrible bottleneck?
>>>
>>>Alternatively, given that Object systems have their own location
transparency schemes, might URN not be relevant here (then we'd have to
rename them FURNs (Fairly Universal Resource Names)? I would have thought
that if URN could be made relevant, it should be.
>>>
>>>Apologies in advance for anyone who wants me to explain these schemes in
any more depth - my knowledge is fairly sketchy.
>>>
>>>Bob

---No 2 in thread---
>>From: [e-mail] (Leslie Daigle)
>>Date: Tue, 11 Mar 1997 14:57:36 -0500
>>To: Bob Briscoe <[e-mail]>, [e-mail]
>>Subject: Re: [URN] URNs grandfathering certain Object or Interface
References
>>
>>Bob,
>>
>>I'm glad you've brought up a couple of emerging electronic namespaces that
>>are clear candidates for URN namespaces.
>>
>>Ron may want to take a more detailed shot at NAPTR and the specific issues
>>you've raised wrt the use of text-replacement only for these namespaces.
>>
>>I'd like to put a little context around the whole issue:
>>
>>    . As Ron is very good about reminding us regularly, NAPTR is
>>      meant to be an _experimental_ implementation of the general
>>      architecture for URN systems.  It is proposed as experimental
>>      specifically so that we can answer questions with concrete
>>      experience on:
>>
>>        . what are the real security issues
>>
>>        .(most relevant here) what _is_ a sufficiently powerful
>>         and yet generally-implementable method for specifying
>>         transformations? (regexps are already dangerously
>>         complex, and yet there are clearly things they cannot do).
>>
>>> The problem is that some COM/CORBA based systems can interpret these
>>> strings of hex digits to extract the machine/port etc. which hosts the
>>> object they need for resolution, but the algorithm isn't a simple textual
>>> transformation.
>>>
>>> How might NAPTR cope with this without just resorting to a replacement
>>> string and lumping the whole problem on one global resolver for the whole
>>> scheme leading to a horrible bottleneck?
>>
>>The key thing to remember with the proposed URN resolution _framework_
>>is that the first step in resolution is to determine the authority
>>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>>this is step one in distributing the problem.  Step two is to perform
>>some kind of lookup at/of that authority to get that information.  The
NAPTR
>>proposal uses the same basic DNS lookup algorithms for both of these
steps, so
>>they start to look the same.  BUT, the key thing in finding a mapping from
>>UUIDs and IORs would be to determine how to find the authority for a
particular
>>one, and then run some kind of local process there  to interpret the
namespace-
>>specific stuff (HEX code, here).
>>
>>So, bringing either of these namespaces into URN-land may not just be a
question
>>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>>may be the case that the process of developing these as URN namespaces will
>>include attaching some reference to the authority that will be responsible
>>for performing the analysis of the HEX representation.
>>
>>For example,
>>
>>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>
>>could become
>>
>>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>>
>>or even
>>
>>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>>
>>The first step in resolving this URN is to identify that it is a clsid
>>namespace URN -- this indicates how to go about finding the naming
>>authority ID, which can be textually extracted from either of the above.
>>
>>Now, if that NA-ID can be mapped onto a machine name in some regular way
>>(forget the pros and cons for a moment) then even NAPTR can be used to
>>look up the alias, find the current address, port and protocol to speak
>>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>>
>>If you don't want to include such a NA-ID in the URN representation of the
>>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>>service (which could be mirrored). Note that the global service doesn't
have
>>to do the entire document resolution - it "only" has to apply the "hex
>>decoding" algorithm to the URN.  If that can't be done quickly, then it
>>would be a bottleneck no matter where it was handled.
>>
>>So, I don't see anything here that really breaks the paradigm of the URN
>>framework acting as a "glue" that ties togethe multiple namespaces. It
>>is a _good_ case of things to test NAPTR against -- are there people
>>involved with defining the UUID and IOR namespaces that are interested in
>>taking on the mapping from those spaces into a URN representation?  This
>>could be a great test-case for our grandfather-a-namespace issue, if
>>somebody that represents those namespaces is willing to take it on.
>>
>>Leslie.
>>
>>--
>>
>>----------------------------------------------------------------------------
>>
>>  "_Be_                                           Leslie Daigle
>>             where  you
>>                          _are_."                 Bunyip Information Systems
>>                                                  [phone]
>>                      -- ThinkingCat              [e-mail]
>>----------------------------------------------------------------------------
>>

---No 3 in thread---
>Date: Wed, 12 Mar 1997 16:25:07 +0000
>To: [e-mail] (Leslie Daigle)
>From: Bob Briscoe <[e-mail]>
>Subject: Re: [URN] URNs grandfathering certain Object or Interface References
>Cc: [e-mail]
>
>At 14:57 11/03/97 -0500, Leslie Daigle wrote:
>>        .(most relevant here) what _is_ a sufficiently powerful
>>         and yet generally-implementable method for specifying
>>         transformations? (regexps are already dangerously
>>         complex, and yet there are clearly things they cannot do).
>>
>
>I would suggest the reference in the CORBA spec I cited would be worth
reading for the thinking on context relative naming from the OMG's members.
There is years of academic thought and history behind it. CORBA naming
interoperability between very different ORB domains is targeting the same
problem as URN.
>
>See CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.5 & 10.6]
>
>>The key thing to remember with the proposed URN resolution _framework_
>>is that the first step in resolution is to determine the authority
>>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>>this is step one in distributing the problem.  Step two is to perform
>>some kind of lookup at/of that authority to get that information.  The
NAPTR
>>proposal uses the same basic DNS lookup algorithms for both of these
steps, so
>>they start to look the same.  BUT, the key thing in finding a mapping from
>>UUIDs and IORs would be to determine how to find the authority for a
particular
>>one, and then run some kind of local process there  to interpret the
namespace-
>>specific stuff (HEX code, here).
>>
>>So, bringing either of these namespaces into URN-land may not just be a
question
>>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>>may be the case that the process of developing these as URN namespaces will
>>include attaching some reference to the authority that will be responsible
>>for performing the analysis of the HEX representation.
>>
>>For example,
>>
>>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>could become
>>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>>or even
>>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>>
>>The first step in resolving this URN is to identify that it is a clsid
>>namespace URN -- this indicates how to go about finding the naming
>>authority ID, which can be textually extracted from either of the above.
>
>Duplicating the <naming authority ID> that is already embedded in the hex
would be ANATHEMA to the reliability and security of the processes for
publishing these names, not to mention performance which is why these
things are stringified to hex rather than ASCII - a big winge the OO
community has about IETF protocols is that they all appear to have been
left permanently in de-bug mode so humans can read the protocol headers (I
personally think this is a GOOD THING, but it does have performance problems).
>
>>
>>Now, if that NA-ID can be mapped onto a machine name in some regular way
>>(forget the pros and cons for a moment) then even NAPTR can be used to
>>look up the alias, find the current address, port and protocol to speak
>>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>>
>>If you don't want to include such a NA-ID in the URN representation of the
>>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>>service (which could be mirrored). Note that the global service doesn't
have
>>to do the entire document resolution - it "only" has to apply the "hex
>>decoding" algorithm to the URN.  If that can't be done quickly, then it
>>would be a bottleneck no matter where it was handled.
>
>Again, this is ANATHEMA to the designers of these systems. We have to
consider gazillions of object refs, bearing in mind that there's one for
each *object* not just each class of *object*. For instance the (fixed
size) DCE/COM name-space has been designed to be larger than the estimated
number of atoms in the universe. The CORBA namespace is gazillions of
orders of magnitude bigger than that (the number of permutations of atoms
in the universe is more relevant to the number of possible permutations of
objects, profiles and service environments).
>
>>
>>So, I don't see anything here that really breaks the paradigm of the URN
>>framework acting as a "glue" that ties togethe multiple namespaces.
>
>I think NAPTR is a neat trick for farming out the problem very early on,
however, I think we may find these object-based schemes do break the
*currently proposed* paradigm (although my understanding of how their names
are constructed is sketchy), simply because of the performance requirements
at huge scale. For instance, BT has already found experimental CORBA-based
systems to be too slow to do 0800 (free phone) look-ups within the 500msec
time budget we have between the end of dialling and ringing (before the
caller hangs up thinking there's a problem). Just object location (id
look-ups) for 4 objects out of c.1million currently takes more than this
time budget. I'm not saying an *experimental* system like NAPTR should meet
these requirements, but I am saying if the intention is to assimilate all
naming, it has to be a *requirement* to *be able to* meet the *highest*
common denominator performance target.
>
>>It
>>is a _good_ case of things to test NAPTR against -- are there people
>>involved with defining the UUID and IOR namespaces that are interested in
>>taking on the mapping from those spaces into a URN representation?  This
>>could be a great test-case for our grandfather-a-namespace issue, if
>>somebody that represents those namespaces is willing to take it on.
>>
>
>I'll refer Charlie Kindel (Microsoft) and Andrew Watson (OMG chief
architect) to the archive entries of this thread. I was going to do this
anyway once I had done an initial sanity check with the URN working group.
>
>Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm